Amazon Web Services(AWS)は、AWS re:Invent 2014で、「Amazon EC2 Container Service」および「AWS Lambda」を発表した。誤解されそうな部分を含めて、これらのサービスの内容と狙いを探った。
Amazon Web Services(AWS)は、2014年11月11〜14日に開催したAWS re:Invent 2014で、2つの「PaaS的」な新サービス、「Amazon EC2 Container Service(ECS)」および「AWS Lambda」を発表した。AWSのプロダクトマーケティング担当AWSプリンシパル、ポール・ダフィー(Paul Duffy)氏は、PaaSなどという分類は関係なく、この2つのサービスはアプリケーション運用について様々な抽象度を提供しようとする同社の取り組みだと説明する。また、どちらもアプリケーションのマイクロサービス化という動きに対応したものといえる。
EC2 Container Service(ECS)は、「Docker対応」だけがひとり歩きして誤解されそうなサービス。これはインフラレイヤを意識せずに、Dockerアプリケーションのデプロイや運用ができるものではない。冒頭で、あえて「PaaS的」と表現したが、開発者フレンドリーではあっても、実際にはIaaSと表現するのがふさわしい。
ECSは、ユーザーがDocker形式のコンテナ化アプリケーション(以下では「Dockerコンテナアプリ」と呼ぶ)を運用できるサービス。ユーザーが任意の数のAmazon EC2インスタンス群を、コンテナ用として設定し、「クラスタ」としてグループ化する。このEC2インスタンス群の上で、複数のDockerコンテナアプリから成る分散アプリケーションを運用できる。
各Dockerコンテナアプリについては、必要とするCPU、メモリといった仕様をJSONファイルに登録しておく。すると、ECSがその仕様に基づき、各アプリを適切なEC2仮想インスタンスに自動配置することで、仮想インスタンスリソースの利用を最適化する。
単一のクラスタに、複数の分散アプリケーション群、つまり複数のDockerコンテナアプリグループを動かして、リソース利用の調停をすることもできるようだ。
ただ、クラスタとして構成されるEC2インスタンスの台数を、アプリケーションニーズに応じて自動的に増減する機能は今のところない。だが、アマゾンデータサービスジャパン技術部長の玉川憲氏は、技術的には難しいことではないので、そのうち提供されるだろうと話している。
つまり、ECSは、EC2インスタンスを意識しなければならないのが面倒だと考える人には適さない。だが、各ユーザー/ユーザー組織のAmazon VPC内で動くため、他のユーザー組織とは論理的に分離されているので、セキュリティ的に安心しやすいし、EC2インスタンスに関するセキュリティグループなどのセキュリティ機能が全て使える。EC2インスタンスのタイプを意識的に選択して構成できる点もメリットという。さらに、運用する分散アプリケーションの規模(Dockerコンテナアプリ数)にも制限はないという。
ECSは「プレビュー」として、限定提供が開始された。このサービス自体は無償だが、上記の仕組みからいえば驚くほどのことではない。あくまでもEC2インスタンスやストレージのサービスであり、これに、Dockerを活用したい開発者のためのツールを付け加えたものだからだ。ユーザーは、ECSのクラスタとして利用するEC2インスタンスおよびストレージの料金を支払う。
AWSは、これまでも「Elastic Beanstalk」というサービスでDockerをサポートしていた。Docker形式のアプリケーションイメージをデプロイする作業は透過的に行えたが、こちらは1仮想インスタンスに1つのDockerコンテナアプリしか動かせず、コンテナを使うことによるリソース利用効率の向上メリットがなかった。さらに、Dockerコンテナアプリのオーケストレーション機能はなく、他のオーケストレーションツールを併用するしかなかった。つまり、複数のDockerコンテナアプリで構成される分散アプリケーションを、複数のEC2インスタンスにまたがって運用することを支援する機能が欠けていた。
一方Lambda(「ラムダ」)は、イベントを受けてリアルタイムで処理するアプリケーションを、インフラをまったくに気にせずに動かせるサービス。プレビューとして、限定的な提供が開始された。
使い方として一番分かりやすいのはInternet of Things(IoT)系のアプリケーション。何らかのセンサーから送られてきたデータをリアルタイムで処理することなどが考えられる。IoTでない使い方の例として、動画サービスのNetflixは、多数の動画供給元からばらばらに送られる動画素材を、その都度多数のフォーマットにトランスコードし、次にこれをデータベースに登録するという一連の作業の自動化に、Lambdaを試し始めているという。
Lambdaでは、コードを大きな単一アプリとして書くのではなく、小さなアプリケーション(「マイクロサービス」)の連続として書くことが基本になる。マイクロサービスを「Function(関数)」と呼び、現在のところはJavaScriptで書いてNode.jsで動かすようになっている。「あなたが写真をリサイズし、ウォーターマークを付けるようなケータイアプリを開発したなら、写真がS3のバケットにアップロードされると、S3の通知機能でこのFunctionが(自動的に)呼び出されて実行される」(ダフィー氏)。
各Functionの実行のきっかけとなるイベントとしては、Amazon S3、DynamoDB、Kinesis、SQSにおける、データ入力や更新などの状態変化を利用できる。
これまでAWSを用いてこうしたアプリケーションを書くには、Amazon EC2インスタンスを立て(あるいはAmazon EC2インスタンスを立ててその上でコンテナを動かし)、イベントを待ち受けするアプリケーションを動かすことが必要だった。Lambraでは、EC2インスタンスやコンテナの運用をユーザーは考えなくていい。AWSがこの部分を隠蔽してくれる。つまり、待ち受けのために、無駄にEC2インスタンスの料金を払い続ける必要がない。また、イベントの発生時刻や発生量が全く予測つかない場合でも、アプリケーションのスケーリングは自動的に行われる。料金体系は、EC2インスタンス単位の課金ではない。Functionで処理するリクエストの数とコードの実行時間の組み合わせで料金が徴収される。
Functionを起動するイベントの種類は、今後増やしていくという。また、現在のところNode.jsでJavaScriptしか使えないが、後述のように、ほかの開発言語、フレームワークへの対応も進めていくと、ダフィー氏は話している。
では、このサービス自体はコンテナベースで動いているのだろうか。AWSはそれを答えようとない。ユーザーがそうしたことにとらわれる必要がないということを目的としたサービスだからだ。だが、各ユーザー組織のFunctionはVPC内で動くため、他のAWSユーザーと分離されるとしている。
以下では、この2つのサービスに関する筆者のダフィー氏への質問と回答の一部をお送りする。
――あなたはECSを、米グーグルのKubernetesベースのサービスや、米レッドハットのOpenShift、米PivotalのCloud Foundryがやろうとしている競合サービスと、どう比較して説明するか?
当社のサービスは顧客のためのものだ。多くのAWS顧客はこれまでDockerコンテナをAWS上で動かしてきた。この人たちはコンテナを使ったコンピューティングが気に入っているが、クラスタの管理やスケジューリングが難しいと感じていた。ECSではEC2インスタンスのクラスタを管理できる。特定量のCPUやメモリのリソースを求めるタスクを動かしたいとき、ECSはそれだけのキャパシティを持ったEC2インスタンスを見つけて、デプロイすることができる。
――インフラを全く意識しないで使えるようなサービスを提供する可能性は?
Lambdaがその定義に当てはまる。何らかのFunctionを動かしたかったら、2、3行であっても、あなたはそれを実行するコードを持ち込みさえすればいい。
――だが、LambdaではJavaScriptしか使えない。
Lambdaがサポートするのは、当初はNode.js/JavaScriptだけだ。しかし、われわれは急速に進化させていくつもりだ。われわれはインフラの使い方についての選択肢を多数提供しようとしている。例えばElastic Beanstalkではインフラを管理しなくていいが、コントロールはできる。ユーザーは必ずしも(完全な)ブラックボックスを望むわけではない。一方、Lambdaのような環境を望む人もいる。Amazon RDSとAuroraの関係も、これに似ている。
――Lambda自体はコンテナベースのサービスなのか。
その質問にどう答えるのが最適かは分からない。ECSについてはそういう表現をしているが、Lambdaについてはそういう説明の仕方はしない。LambdaのFunctionをつくり、アップロードしさえすれば、イベントをきっかけとして、それが実行されるということだ。
Copyright © ITmedia, Inc. All Rights Reserved.